\chapter{Apéndice}

	% á
	% é
	% í
	% ó
	% ú
	% ñ

\section{Lenguaje XML (Extensible Markup Language)}\label{xml}

		\textit{XML}\footnote{Para más información, visite \url{http://www.w3.org/TR/REC-xml/}} es un lenguaje de marcas que ofrece un formato para la descripción de datos estructurados. Es decir, \xml es un metalenguaje, dado que con él podemos definir nuestro propio lenguaje de presentación y, a diferencia del \textit{HTML}, que se centra en la representación de la información, \xml se centra en la información en si misma. La particularidad más importante del \xml es que no posee etiquetas prefijadas con anterioridad, ya que es el propio diseñador el que las crea a su antojo, dependiendo del contenido del documento.\\
		\xml es un formato basado en texto. Un documento \xml se compone de elementos \xml, cada uno de los cuales consta de una etiqueta de inicio, de una etiqueta de fin y de los datos comprendidos entre ambas etiquetas. Al igual que los documentos \textit{HTML}, un documento \xml contiene texto anotado por etiquetas. Sin embargo, a diferencia de \textit{HTML}, \xml admite un conjunto ilimitado de etiquetas, no para indicar el aspecto que debe tener algo, sino lo que significa. Por ejemplo: un elemento \xml puede estar etiquetado como precio, número de pedido o nombre. El autor del documento es quien decide qué tipo de datos va a utilizar y qué etiquetas son las más adecuadas.\\
		Los documentos \xml son fáciles de crear. En este ejemplo se utiliza \xml para describir un parte meteorológico. Este documento se puede guardar con una extensión de \xml, por ejemplo Tiempo.xml.\\
		
\begin{lstlisting}[language=XML, morekeywords={reporte\_clima, fecha, hora, area, departamento, ciudad, pais, medidas, cielo, temperatura, viento, direccion, velocidad, h\_indice, humedad, visibilidad, uv\_indice}]		
<reporte_clima>
  <fecha>Marzo 25, 1998</fecha>
  <hora>08:00</hora>
  <area>
    <departamento>MVD</ departamento >
    <ciudad>Montevideo</ciudad>
    <pais>Uruguay</pais>
  </area>
  <medidas>
    <cielo>parcialmente nublado </cielo>
    <temperatura>16</temperatura>
    <viento>
    <direccion>SO</direccion>
    <velocidad>16</velocidad>
    </viento>
    <h_indice>51</h_indice>
    <humedad>87</humedad>
    <visibilidad>10</visibilidad>
    <uv_indice>1</uv_indice>
  </medidas>
</reporte_clima>
\end{lstlisting}
		


\section{El lenguaje de programación C++}

\textit{C++} es un lenguaje de programación desarrollado en el año 1979 por \textsc{Bjarne Stroustrup} en los laboratorios \textsc{Bell}. 
El nombre \textit{C++} fue propuesto por \textsc{Rick Mascitti} en el año 1983, cuando el lenguaje fue utilizado por primera vez fuera de un laboratorio científico. Antes se había usado el nombre \textit{``C con clases"}. En \textit{C++}, la expresión ``C++" significa \textit{incremento de C} y se refiere a que \textit{C++} es una extensión de \textit{C}.
 
Los contenidos más completos sobre este lenguaje se los pueden encontrar en el propio libro de \textsc{Bjarne Stroustrup} \cite{cplusplus}.\\

\textit{C++} es un lenguaje multi-paradigma y estáticamente tipado. Es considerado un lenguaje de nivel medio, ya que comprende características de lenguajes de alto y bajo nivel.
 Este lenguaje ofrece nuevos tipos de datos, clases, plantillas, mecanismo de excepciones, sistema de espacios de nombres, funciones inline, sobrecarga de operadores, referencias, operadores para manejo de memoria persistente, y algunas utilidades adicionales de librería para facilitar la resolución de determinados problemas, permitiendo al programador concentrarse en dichos problemas y no en implementar tipos de datos abstractos ya conocidos.


\section{Unified Modeling Language (UML)}

		Los Diagramas de Estructura Estática de \textit{UML}\footnote{Para más información, visite \url{http://www.clikear.com/manuales/uml/diagramasestructuraestatica.aspx}} se utilizan para representar tanto modelos conceptuales como Diagramas de Clases de Diseño, convirtiéndola en una herramienta útil a la hora de diseñar el sistema en cualquiera de sus niveles. Este lenguaje gráfico provee notación estándar para la documentación de elementos tales como: bases de datos, clases, conexiones, etc. y pudiendo especificar métodos, funciones e interacciones entre estos \cite{JaGor05}.
		\textit{UML} provee una extensa cantidad de elementos para desarrollo en la ingeniería del software, pero solo describiremos los utilizados en este trabajo.
		
\subsection{Notas}

		Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Una nota se representa como un rectángulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc. 

\begin{figure}[ht]
\centering
\includegraphics[scale=0.7]{Pictures/d5.jpeg}	  	
\caption{\small Ejemplo de notas.} 
\end{figure} 

\subsection{Dependencias}

		La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen). Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a él está la flecha). 
	
\begin{figure}[ht]
\centering
\includegraphics[scale=0.8]{Pictures/5_depend_uml.jpg}
\caption{\small Ejemplo de dependencias.} 
\end{figure} 	

\subsection{Clases, atributos y métodos}

		Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior los métodos. Una clase puede representarse de forma esquemática, con los atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la Fig. \ref{fig:EjemploClases} se ve cómo una misma clase puede representarse a distinto nivel de detalle según interese, y según la fase en la que se esté.
		 
\begin{figure}[ht]
\centering
\includegraphics[scale=0.7]{Pictures/5_clases_uml.jpeg}
\caption{\small Ejemplo de clases.}
\label{fig:EjemploClases}
\end{figure} 
		
\subsection{Relaciones entre clases}

\subsubsection{Asociaciones}
	Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación. A continuación se verán los más importantes. 

\paragraph{Nombre de la asociación y dirección}
	El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación. En el ejemplo de la Fig \ref{fig:EjemploAsociacion} se puede leer la asociación como “Director manda sobre Empleado”.
	
\begin{figure}[ht]
\centering
\includegraphics[scale=0.7]{Pictures/5_nom_a_uml.jpg}
\caption{\small Ejemplo de la asociación y dirección.}
\label{fig:EjemploAsociacion}
\end{figure} 

	Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregación y de herencia no se suele poner el nombre. 

\paragraph{Multiplicidad}

\begin{figure}[ht]
\centering
\includegraphics[scale=0.7]{Pictures/d3.jpeg}
\caption{\small Ejemplo de Multiplicidad.} 
\end{figure} 
	
	La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. Puede expresarse de las siguientes formas:
	
\begin{itemize}
	\item Con un número fijo: 1.
	\item Con un intervalo de valores: 2..5.
	\item Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más.
	\item Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*.
	\item Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más).
\end{itemize} 
		
\paragraph{Roles}
	Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. 
	
\begin{figure}[ht]
\centering
\includegraphics[scale=0.7]{Pictures/d6.jpeg}
\caption{\small Ejemplo Roles.} 
\end{figure} 		
	
	Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol. 

\paragraph{Agregación}
	El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el “todo”.
	 
\begin{figure}[ht]
\centering
\includegraphics[scale=0.6]{Pictures/d1.jpeg}
\caption{\small Ejemplo Agregación.} 
\end{figure}
	
\subsection{Herencia y polimorfismo}
	La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase base o clase más general.
	
\begin{figure}[ht]
\centering
\includegraphics[scale=0.7]{Pictures/d2.jpeg}
\caption{\small Ejemplo Herencia.} 
\end{figure}

\pagebreak
\section{Patrones de Diseño}
	
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón describe un problema que ocurre varias veces en un sistema, y la base de la solución a ese problema. Los patrones de diseño son el resultado del consenso de profesionales en el área y brindar herramientas a los diseñadores de sistemas para no escoger malos caminos, valiéndose de documentación disponible en lugar de simplemente la intuición.
	    
\subsection{Patrones}

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias. Cada patrón de diseño se focaliza sobre un problema
o issue particular de diseño (DOO).
 En general, un patrón tiene cuatro elementos esenciales:
\begin{itemize}
	\item[1.] \textbf{El nombre del patrón} es un manejador que se usa para describir un	problema de diseño, su solución y consecuencias.
	\item[2.] \textbf{El problema} describe cuándo aplicar el patrón, explica el problema	 y su contexto. También describe problemas de diseño específicos tales como ``Como representar un algoritmo como un objeto''. Además describe la estructura de clases y objetos que son sintomáticas de un diseño inflexible. A veces, el problema puede incluir una lista de condiciones que deben ser reunidas antes de 			que tenga sentido aplicar el patrón.
	\item[3.] \textbf{La solución} describe los elementos que integran el diseño, sus relaciones, responsabilidades y colaboraciones. La solución no describe un diseño particular concreto o implementación, ya que un patrón puede ser aplicado en muchas situaciones diferentes. De hecho, un patrón provee una descripción abstracta de un problema de diseño y cómo una disposición general de los elementos los resuelve.
	\item[4.] \textbf{Las consecuencias} son los resultados y compromisos de aplicar el patrón. éstas son fundamentales para evaluar alternativas de diseño y para la comprensión de los costos y beneficios de aplicar el patrón. Las consecuencias de un patrón incluye su impacto sobre la flexibilidad del sistema, expansión o portabilidad.
\end{itemize}


\subsection{Patrones utilizados en este trabajo}
A lo largo del proceso de diseño se encontraron problemas que coincidían con patrones. Estos patrones se explican brevemente a continuación: 

\begin{itemize}
	\item \textbf{Observer}: Define una dependencia uno a muchos entre objetos, de forma que si un objeto cambia de estado, todos sus dependientes son notificados y actualizados automáticamente.
	 En la Fig. \ref{fig:PatronObserver} se ve el modelo estándar del patrón.

\begin{figure}[ht]
\centering
\includegraphics[scale=0.8]{Pictures/Pattern_Obs.png}
\caption{\small Patrón Observer.}
\label{fig:PatronObserver}
\end{figure}


\textit{Aplicabilidad: } Se usa el patrón \textit{Observer} cuando 
	\begin{itemize}
    	\item Una abstracción tiene dos aspectos, uno dependiente del otro. Encapsular estos aspectos en objetos por separado le permite 					variarlo y reutilizarlos de manera independiente.
    	\item Un cambio de un objeto requiere cambiar a los demás, y no sé sabe cuantos objetos hay que cambiar.
		\item Un objeto debe ser capaz de notificar a otros objetos sin hacer suposiciones acerca de que son estos objetos. En otras 						palabras, no se quiere que los objetos estén muy acoplados.
	\end{itemize}
\end{itemize}


\section{Principios de Diseño (DOO)}
Dentro de la programación orientado a objetos, existen diferentes principios que ayudan en la elección del modelado de clases, y cómo estas clases deben interactuar.\\

\subsection{SOLID}
SOLID \textit{(Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)} es un acrónimo memotécnico introducido por \textsc{Robert C. Martin} a comienzos del 2000 el cual se basa en 5 patrones básicos de diseño y programación orientada a objetos. Cuando los principios se aplican conjuntamente hacen más probable que un programador cree un sistema de fácil mantenimiento y extensible en el tiempo.

\paragraph{Principio de Simple Responsabilidad (SRP)}
En la programación orientada a objetos, el Principio de Simple Responsabilidad, establece que cada objeto debe tener una única responsabilidad, y que la responsabilidad debe ser completamente encapsulado por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.

\paragraph{Principio de Apertura/Cierre (OCP)}
El principio de apertura/cierre establece que ``entidades de software (clases, módulos, funciones, etc) deben quedar abiertas a la extensión, pero cerradas para su modificación'', es decir, una entidad puede permitir que su comportamiento pueda ser modificado sin alterar su código fuente. 

\paragraph{Principio de sustitución de Liskov (LSP)}
El principio de sustitución de Liskov es una definición particular de una relación de subtipificación, llamado subtipificación de comportamiento, que fue introducido inicialmente por Barbara Liskov. Establece que ``los tipos derivados deben poder ser sustitutos completos de sus tipos base".

\paragraph{Principio de Segregación de Interfaz (ISP)}
El principio de interfaz de la segregación dice que una vez que una interfaz se ha puesto demasiado ``gorda" tiene que ser dividida en partes más pequeñas y más interfaces específicas para que cualquier cliente de la interfaz pueda sólo saber acerca de los métodos que les pertenecen. En pocas palabras, ningún cliente debería ser obligado a depender de métodos que no utiliza.

\paragraph{Principio de Inversión de Dependencia (DIP)}
El principio de inversión de dependencia promueve que hay que depender de abstracciones, no de concreciones. Dicho de otra forma, los módulos de más alto nivel no deben depender de los de más bajo nivel sino que ambos deben depender de abstracciones. Y a su vez, las abstracciones no deben depender de los detalles sino al contrario.

\section{Pseudo Código}
A lo largo del trabajo se definieron algoritmos utilizando un pseudo código similar a C. Este no pertenece a ningún estándar pero creemos conveniente su utilización.

\subsection{Gramática}
Utilizamos notación formal para denotar la gramática.

\begin{lstlisting}[basicstyle=\tt, tabsize=2, fontadjust=true]
<sentence> :: = <sentence>..<sentence>
			| while <sentence> do { <sentence> }			
			| for each <element> in <set of elements> { <sentence> }
			| if <sentence> { <sentence> } else { <sentence> }
			| <type> <element>
			| <element> = <element>
			| type <namefunction>(<element>,..,<element>) {<sentence>}
			| return <element>
			| case (<element>) {<element>: <sentence>...<element>: <sentence>}
			
<type> :: = C++ types

<element> :: = C++ instance
\end{lstlisting}

Es decir este pseudo código trata de imitar al de \textit{C++} eliminando algunos elementos que no son necesarios para el caso, como iteradores, estructuras, clases, puntos y coma, entre otras cosas.


